Carrier aggregation (CA) was initially introduced in Release 10 to increase the available bandwidth and hence the achievable data rate in a Long Term Evolution (LTE) system up to 1 Gbps in downlink (DL) and 500 Mbps in uplink (UL). This is accomplished by aggregating multiple component carriers (CCs) that can be jointly used for UL and/or DL transmissions both in Frequency Division Duplex (FDD) and Time Division Duplex (TDD) configurations. In particular, LTE CA considers the possibility to aggregate up to 5 CCs potentially of different bandwidths (e.g., 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, 20 MHz), thus pushing the maximum aggregated bandwidth to 100 MHz. A key feature of CA is that the aggregation can take place across CCs that are not necessarily contiguous in frequency at the expense of additional user equipment (UE) complexity. As such, operators possessing a fragmented spectrum can still boost the achievable data rate even though they are not provided with a large enough single wideband carrier.
The introduction of CA has the side effect of increasing UE battery power consumption because a UE needs to monitor in parallel multiple DL carriers and also multiplex transmissions over multiple UL carriers. This problem may become even more severe in cases of inter-band carrier aggregation where CCs are not located within the same operating frequency band, and the UE is required to execute multiple receiver/transmitter chains simultaneously. For this reason, CA is typically activated/deactivated by the network on a UE basis in a dynamic fashion according to some specific rules, such as the DL/UL traffic demands, the channel quality, or some load balancing policies that force the UE to move to some specific carriers.
More specifically, a CA-capable UE can be provided with a primary carrier (PCell) and one or more secondary carriers (SCell), where each carrier looks like a cell with its own physical identity. According to 3GPP, some operations are supposed to be handled only by the PCell (e.g., the Physical Uplink Control Channel (PUCCH) Uplink Control Information (UCI) transmissions, the Contention Based Random Access (CBRA), the Radio Resource Control (RRC) signaling, and the Non-Access Stratum (NAS) information). The selection of PCell and SCell(s) is also UE specific, and similar strategies previously described can be adopted to select the PCell and the SCell(s).
An extension of legacy CA functionality is currently under standardization in 3GPP Release 13. The objective of this enhancement is to increase the amount of supported CCs up to 32 to give additional flexibility to the CA settings. For example, one possible setup could be to combine this new feature with a License Assisted Access (LAA) framework, thereby providing the possibility to aggregate unlicensed CCs (e.g., Wi-Fi bands) together with licensed carriers for a maximum number of 32 aggregated CCs.
FIG. 1 illustrates an example of cross-carrier scheduling. Cross-carrier scheduling is one important feature of CA. It is possible with cross-carrier scheduling to send DL scheduling assignments and UL scheduling grants on Physical Downlink Control Channel (PDCCH) from a different CC than the one actually scheduled. FIG. 1 illustrates a number of CCs, including PCell 5, SCell1 10, and SCell2 15. Each CC carrier includes a PDCCH portion 20 and a data portion 25. As shown in the example of FIG. 1, PDCCH portion 20 of PCell 5 includes DL scheduling assignments and/or UL scheduling grants for SCell1 10 and SCell2 15 (indicated by arrows 30 and 35, respectively). As such, PDSCH and PUSCH can be sent on a CC other than the one on which the related PDCCH has been received. This is in contrast to the scenario without cross-carrier scheduling (illustrated by arrow 40). Different benefits can be envisaged for this feature. As one example, cross-carrier scheduling may allow balancing of the inter-cell interference caused by the PDCCH. As another example, cross-carrier scheduling may be used for load balancing purposes (especially taking into account that the size and the bandwidth of the different deployed carriers can be significantly different).
The cross-carrier scheduling mechanism can be enabled/disabled independently for each CC via RRC signaling. The cross-carrier scheduling mechanism leverages a 3-bit Carrier Indicator Field (CIF) carried by a PDCCH. This CIF indicates to which carrier a certain DL scheduling assignment or UL scheduling grant refers. A CIF having a size of 3 bits can take on 8 different values. Thus, with the 3-bit CIF, a maximum of 8 carriers can be cross-carrier scheduled. In addition to indicating which carrier a certain DL scheduling assignment or UL scheduling grant refers, the CIF can also be used in other scenarios. For example, the CIF can be used for PDCCH order to order a UE to perform Contention Free Random Access (CFRA) on a particular carrier.
As described above, the 3-bit CIF can be used in PDCCH for cross-carrier scheduling. With the current CIF size, it is not possible to address more than 8 carriers. Before 3GPP Release 13, this limitation was not a problem since no more than 5 carriers can be aggregated. In 3GPP Release 13, however, the amount of carriers that can be aggregated will increase to 32. The 3-bit size of CIF therefore limits the cross-carrier scheduling capability in 3GPP Release 13. Similar limitations hold for other cases in which CIF is used, such as in the case of PDCCH ordering described above.
One possible approach to the problem posed by increasing the number of carriers that can be aggregated is to increase the length of the CIF to 5 bits in order to accommodate all of the 32 possible carriers. Such an approach, however, has the side effect of increasing the PDCCH size and implies resource wastage in case not all the 32 carriers are configured. Furthermore, there is the issue of whether there is a need to support the case where all 32 CCs are scheduled by a single CC. In addition, the DL control channel capacity limitation and (E)PDCCH/PHICH blocking/collision needs to be resolved if this is deemed to be supported.
Based at least in part on these reasons, 3GPP has agreed to not change the size of the CIF and to keep using the 3-bit CIF in Release 13. Thus, there is a need for new mechanisms that can allow cross-carrier scheduling of more than 8 carriers without changing the size of the CIF.